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The  “International  Conference  on  Stiff  Computation"  was  held 
in  Park  City,  Utah  April  12,  13  and  14,  1982  as  announced  in  the 
brochure,  labeled  Appendix  I.  This  announcement  was  sent  to 
approximately  1000  individuals;  the  names  were  acquired  from  our 
data  base  of  authors  of  papers  on  the  conference  topic  since 
1972.  An  advertisement  also  appeared  in  BIT  and  SIAM 
newsletters . 

The  meeting  was  attended  by  approximately  45  individuals. 
About  33  of  these  presented  a  paper,  of  which  approximately  20 
were  invited  with  various  levels  of  support.  (See  Appendix  II 
for  listing  of  speakers). 

•^The  purpose  of  the  meeting  was  to  examine  state-of-the-art 
software  development  and  theory  for  the  numerical  solution  of 
stiff  ordinary  differential  equations  as  it  relates  to 
application  demands  of  today  and  tomorrow. (Orfe  intentionally 
tried  to  have  represented  software  developerVvpractitioners,  and 
theoreticians  approximately  in  equal  numbers .  ^Ttns  mixture 
proved  to  be  effective  in  achieving  our  aim  and  fb\a  very 
exciting  meeting,  as  everyone  with  whom  I  spoke  agre^tk. 

A  panel  discussion  at  the  meeting  was  particularly  effective 
in  advancing  our  objectives.  A  transcript  to  part  of  that 
discussion  is  attached  in  Appendix  III.  It  was  intersting  to 
hear  very  different  viewpoints  from  the  three  separate  (but 
overlapping)  groups  present: 

i) .  Software  developers  generally  feel  the  basic  stiff 
problem  (for  which  they  have  a  very  specific  definition)  is 
rather  well  worked  out  but  additional  difficult  model  features 
such  as  discontinuities,  largeness,  high  frequency  oscillation, 
etc.  need  special  software  attention. 

ii) .  Practitioners  want  more  powerful  and  automatic 
software  particularly  for  distributed  systems  modeled  by  PDE’s, 
such  as  transport  and  reaction. 

i 1 i ) .  Theory  developers  are  well  behind  what  is  needed  from 
them  but  are  advancing  into  nonlinear  stability  necessary  for 
stiff  method  analysis. 

These  observations  are  echoed  in  response  to  a  questionaire 
that  was  sent  out  following  the  meeting  (see  Appendix  III  for 
answers  to  these).  Particularly  interesting  was  the  lack  of 
recognition  of  all  attendees  of  the  effect  next  generation 
computers  would  have  on  software  development  and  advancement  in 
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8.1.  The  Questionnaire 

Eight  'stiff  questions'  were  asked  of  each  attendee 
following  the  Park  City  International  Conference  on  Stiff 
Computation.  A  total  36  written  responses  were  received, 
representing  92  per  cent  of  the  attendence.  The  questions  were 
intended  to  be  important,  general,  and  not  of  the  type  typically 
asked  speakers  during  a  conference  presentation.  The  questions 
and  quite  candid  responses  follow: 

QUESTION  1:  Should  the  term  stiff  be  reserved  for  the  initial- 
value  ODE  problem  with  sharp  initial  transients  or  could  it  be 
used  in  a  wider  sense  (differential  algebraic,  discontinuous, 
large  sets,  highly  oscillatory,  TPBVPs,  PDE/BVPs  with  sharp 
transients,  etc.)?  Should  another  general  term  be  defined? 
Should  a  number  of  terms,  one  for  each  specific  type  of 
difficulty,  be  defined?  Bow  i^ortant  is  terminology? 

Bickart:  1  tend  to  be  againet  the  coining  of  too  many  terms .  JT 
am  quite  content  to  have  the  term  stiff  mean ,  as  I  think  it  has 
come  to  mean,  a  dynamic  system  exhibiting  both  quickly  and  slowly 
changing  modes  in  such  a  manner  that  a  numerical  solution  process 
for  its  solution  must  be  stable  for  all  etepeisee  to  facilitate 
efficiency  in  the  solution  process . 

Byrne:  The  indicated  definition  is  really  appropriate  f°r 

linear  constant  coefficient ,  ordinary  initial  -  value  problems 
(first-order  equation  or  system  of  equations) .  Other  definitions 
of  stiffness  are  concerned  with  the  eise  of  the  smallest  time 
constant  and  the  length  of  time  of  the  phenomenon  that  causes  the 
small  time  constant .  For  parabolic  PDEe,  stiffness  can  be 


attributed  to  a  reactive  source/sink  term .  I  would  not  be 
uncomfortable  with  the  use  of  stiffness  for  differential- 
algebraic  systems  (nonstiff  integrator  costs  too  much  —  a 
pragmatic  definition  of  a  stiff  system  in  any  case).  Of  course, 
terminology  is  used  in  the  ODE  community  to  identify  a  specific 
problem  type  and  software  requirements .  I  feel  definition  is 
important . 

Cash:  I  think  that  the  term  stiff  should  only  be  used  for 
initial  value  ODE  problems  at  present.  Certainly,  it  should  not 
be  used  so  widely  for  two-point  boundary-value  problems  as  it 
is.  When  we  define  more  precisely  what  we  mean  by  stiff  I  see  no 
reason  why  the  term  could  not  be  extended  to  certain  problems  in 
the  other  classes  you  mention  ( particularly  to  parabolic  PDEs), 
I  feel  that  the  correct  terminology  is  extremely  important, 
particularly  to  guard  against  using  stiff  solvere  as  black  boxes 
on  the  wrong  sort  of  problems , 

Cellier:  .  ..What  do  you  need  the  terminology  for?  I  am  rather 
pragmatic .  I  feel  that  the  term  should  help  people  in  solving 
their  problems .  Therefore,  if  I  use  the  term  freely  to  denote 
almost  any  integration  problem  which  is  numerically  difficult  to 
solve,  the  only  thing  a  potential  user  can  kn. v  is  the  fact  that 
he  has  a  difficult  problem  to  solve  and  may  be  forced  to  consult 
a  specialist .  This  may  be  useful  information,  but  it  may  then  be 
more  straightforward  to  call  this  term  ' difficult  problem '  rather 
than  ' stiff  problem' .  If  we  restrict  the  term  stiffness  to  mean 
only  a  particular  class  of  difficult  problems .. .this  information 
is  more  useful,  as  the  potential  problem  solver  may  then  already 
know  which  integration  technique  to  apply.  Other  classes  of 
difficult  problems  (i.e./  highly  oscillatory  problems)  may  also 
be  defined,  which  again  would  tell  the  user  which  integration 
technique  to  apply.  Ideally ,  an  algorithm  should  be  designed 
which  can  analyse  a  system  description  and  find  out  for  the  user 
to  which  class  of  problems  his  system  belongs ... 
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Dove:  I  suspect  that  the  term  etiff  will  he  used  in  a  broader 
eenee  whether  we  like  it  or  not.  From  the  user's  viewpoint  thie 
poeee  real  rieke  that  inappropriate  eoftware  will  he  eeleoted  for 
particular  probleme ,  For  thie  reaeon ,  there  may  he  real 
advantages  in  developing  a  more  descriptive  terminology  for  the 
various  types  of  difficulty.  The  objectives  of  such  terminology 
would  include  alerting  the  user  to  the  fact  that  there  are 
various  kinds  of  difficulty  and  helping  to  guide  him  or  her 
towards  appropriate  eoftware . 


Enright:  There  are  two  characteristics  of  stiffness  that  are 
essential.  The  first  is  that  the  mathematical  problem  is  well 
conditioned  and  stable  in  the  sense  that  small  perturbations  mg' 
in  initial  conditions  or  in  the  differential '  equation  lead  to 
small  changes  in  the  solution.  The  second  characteristic  is  that 
when  an  attempt  is  made  to  integrate  the  problem  with  standard 
methods,  a  severe  etepeise  restriction  results  from  the 
constraints  of  numerical  stability .  Without  both  of  these 
characteristics  a  problem  should  not  be  considered  stiff.  For 
example,  highly  oscillatory  initial-value  problems  are  not  etiff 
even  though  it  is  frequently  the  case  thtat  the  inital  conditions 
contain  no  high  —  frequency  components  and  the  latter 
characteristic  is  present.  The  former  characteristic  is  not 
present  as  a  small  change  in  the  initial  conditions  or  in  the 
accuracy  requirements  could  result  in  a  very  different  solution 
and,  in  this  ease,  the  etepeise  of  standard  methods  would  be 
determined  by  accuracy  rather  than  numerical  etability. 

Pinlayson:  I  believe  that  a  two-point  boundary-value  problem, 
when  treated  as  a  PDE  that  gives  a  set  of  equations  whose 
eigenvalues  are  widely  separatedj  ( should  be  considered)  a  etiff 
problem.  It  might  be  useful  to  have  a  separate  nomenclature,  but 
such  a  problem  qualifies  as  etiff  according  to  criteria  such  as 
max  | |/«in| | •  Perhaps  there  should  be  sub-classifications 
under  etiff l 


Gears <  Jt  should  be  reserved  for  systems. . .for  which  the  stable 
timestep  of  an  explicit  method  is  much  smaller  than  that 
necessary  to  track  the  solution .  This  does  not  imply  sharp 
initial  transients ,  or  vice  versa,  y ’  ■  -10s  (y-1 ),  y(0)  *  1  is 
stiff  but  has  no  transient ;  y'  -  -l(Tse~ls  has  a  transient, 

but  is  not  stiff. 

Hindaarsh:  ' Stiff'  should  be  restricted  to  initial-value 

problems  for  ODES,  and  possibly  differential-algebraic  systems, 
with  one  or  more  highly  damped  modes  (and  time  constant  small 
compared  to  the  solution  scale).  Using  'stiff1  for  other  types 
of  difficulties  only  causes  confusion. 

Krogh:  The  only  other  place  where  use  of  the  term  might  be 

justified  ie  for  boundary- value  problems  with  sharp  transients, 
or  which  would  have  sharp  transients  with  a  small  perturbation  in 
the  boundary  conditions .  For  the  other  case,  the  words  you  use 
are  just  fine. 

Nattheij  and  Soderlind:  Today  it  ie  widely  recognised  that  stiff 
JVPs  call  for  methods  with  special  stability  properties,  i.e.w-^~ 
the  stability  set  should  contain  most  of  the  left  half  plane.  Jt 
ie  also  well  known  that  methods  aimed  at  nonstiff  problems  (e.g.,  <- 
implicit  Adams  methods )  for  stability  reasons  are  very 
inefficient  when  applied  to  stiff  problems,  despite  the  fact  that 
they  locally  are  highly  accurate.  Thus  stiffness  is  a  conflict 
between  stability  and  accuracy  requirements  that  appears  in 
certain  problems.  Needless  to  say,  definitions  of  stiffness  that 
cannot  account  for  this  simple  observation  are  not  conceptually 
corrrect.  Unfortunately,  the  classical  definitions  of  stiffness 
fail  because  they  are  based  exclusively  on  mathematical 
properties  of  the  differential  equation,  and  have  thus  caused 
severe  misunderstandings .  Obviously,  a  number  of  different 
terms,  one  for  each  specific  type  of  difficulty,  would  be 
appropriated  as  long  as  the  difficulties  have  different 
origins .  Note,  however,  that  the  mentioned  conflict  between 


stability  and  accuracy  requirements  ie  very  general  indeed . 
Since  it  may  well  appear  in  differential-algebraic ,  dieontinuoue 
and  highly  oscillatory  problems,  there  ie  no  reason  why  the  term 
stiffness  should  be  not  used  in  such  cases .  Even  for  certain 
classes  of  BVPe ,  a  proper  definition  of  stiffness  carries  over  ad 
verbatim,  although  for  general  BVPS  the  notion  of  numerical 
stability  seems  far  from  being  as  well  understood  as  in  the  IVP 
ease.  This  ie,  however,  probably  due  to  the  fact  that  numerical 
methods  for  BVPe  in  general  are  more  complex  than  methods  for 
IVPS .  For  this  reason  there  is  also  a  significant  lag  between 
the  development  of  mathematical  software  for  IVPe  and  BVPe . 

O'Malley:  The  IVP  people  seem  to  have  developed  a  special, 
nearly  self-contained  literature  for  ODEs  which  now  includes  a 
sequence  of  rapidly  converging  definitions  of  stiff  ( for  their 
problems ).  The  brooder  computing  public ,  however,  views  stiff 
problems  as  tough  ones  whose  analytical  solutions  involve 
intervals  of  rapid  transition  and  whose  numerical  solutions  can 
easily  require  (due  to  stability  considerations)  use  of  very 
small  etepfsises  in  regions  where  solutions  are  smooth,  I  prefer 
and  would  suggest  using  the  term  very  loosely,  recognising  that 
IVPe  which  are  stiff  ' in  the  technical  sense*  are  best 
understood.  I  would  not,  in  any  way,  restrict  or  deter  research 
on  grounds  of  established  terminology  or  turf.  In  particular,  I 
would  like  to  emphasise  the  point  that  stiff  BVPe  for  ODEs  and 
PDEe  are  in  very  critical  need  of  analytical  and  numerical  study. 

Schiesser:  The  term  stiff  should  be  reserved  for  the  initial- 
value  problem  in  ODEs  with  sharp  initial  transients .  The 
clearest  definition  of  a  stiff  problem  for  me  ie  one  in  which  the 
product  of  the  problem  time  scale  and  the  largest  eigenvalue  is 
large  (much  greater  than  one).  All  of  the  other  problems 
mentioned  in  the  question  are  important,  but  I  think  they  should 
somehow  be  described  with  other  words  and  terminology  so  we  know 
what  problems  we*re  discussing.  Otherwise,  as  mentioned  at  the 
conference,  any  difficult  problem  ie  termed  stiff. 


Shaapine:  I  believe  it  ie  important  to  develop  a  reasonable 
terminology .  It  impedes  research  and  causes  users  of  software  to 
select  the  wrong  tools  if  the  same  term  is  used  for  fundamentally 
different  phenomena .  For  example,  I  belive  that  the  wide-spread 
belief  that  algebraic-differential  systems  are  virtually  the  same 
as  differential  systems  has  caused  both  the  difficulties  I 
mentioned .  Also,  I  believe  that  highly  oscillatory  problems  are 
fundamentally  different  from  stiff  problems . 

Wendt:  The  term  stiff  should  SOT  be  reserved  for  initial-value 
ODE  problems .  A  wide  sense,  certainly,  involving  boundary- value 
problems,  must  be  included .  Stiffness  arises  from  certain 
aspects  of  physical  problems.  Flames .. .should  be  considered 
stiff,  especially  since  attempts  to  solve  (these)  equations  led 
to  identification  of  stiffness  as  a  mathematical  problem. 

QUESTION  2:  Has  there  been  an  interaction  in  the  past  between 
the  hardware  developers  and  the  software  (and  theory) 
developers?  Has  this  interaction  or  would  such  an  interaction 
have  been  an  advantage  to  either  group?  Will  this  interaction  be 
iaportant  in  the  future;  why? 

Bickart:  I  believe  such  interaction  has  taken  place  quite 
naturally,  but  largely  informally .  I  see  no  special  need  to 
force  it  as  concerns  the  numerical  solution  of  equations  for 
dynamic  systems.  Auxilliary  array  processors  as  a  common-place 
item  are  on  the  way.  I  don't  see  a  special  need  for  auxilliary 
processors  designed  to  implement  a  specific  solution  process . 

Byrne:  IEEE  floating  point  chip  design  used  by  INTEL  and  others 
is  an  example  (Kahan) . . .the  Gleneder  Beach,  Oregon,  conferences 
sponsored  by  DOE,  LLNL,  and  Los  Alamos  National  Laboratories 
bring  users,  manufacturers,  and  code  writers  together  to  dieeuee 
iesuee  related  to  large-scale  computing  --  future  and  present. 
Of  course  it's  important ... 


Cash:  J  believe  that  in  the  future  there  will  be  more 
interaction  between  hardware  and  eoftware  developers •  About  to 
appear  ie  an  important  paper  by  Ower  and  Chereha u,  who  propose  a 
new  form  of  computer  arithmetic  to  deal  with  error  analysis .  The 
interaction  between  software  and  theory  developers  is  absolutely 
vital  and  of  mutual  benefit .  On  the  one  hand ,  we  know  that 
theory  ie  unable  to  predict  much  of  what  happens  in  practice  at 
present  and  software  writers  need  to  discover  the  way  ahead  by 
numeriea l  experiment ... 


Cellier:  Such  an  interaction  has  partly  taken  place  —  and  is 
indeed  useful .  To  state  an  example:  array  processors  have  been 
developed  which  are  useful  tools  but  incredibly  difficult  to 
program  without  appropriate  interface  to  the  software  side .  In 
numerical  integration  of  differential  equations ,  many  subtasks 
can  ~be  formulated  as  vector  operations  fusing  the  same  operation 
on  different  data ,  that  is:  a  SIMD  structure) .  It  may  thus  be 
advantageous  to  compute  these  vector  operations  in  parallel . 


This  is, 

%£  th. 


however ,  only  possible  if 

hardware  specialist  has  designed  hie  computer  such  that 


the  parallel  featuree  can  be  addressed  conveniently  and 


efficiently ,  and 

the  software  designer  makes  use  of  these  featuree  by 
separating  such  vectorial  operations  in  a  modular  way  (e,g»^~ 
by  using  UNPACK  of  which  a  version  may  be  provided  which 


makes  use  of  the  hardware  vector  operations) . 


This  ie  only  one  possible  application .  In  principle ,  this  ie  a 
question  of  properly  designing  the  interfaces .  Some  interfaces 
may  have  to  do  with  other  pieces  of  already  existing  or  still-to- 
be  generated  software ,  others  with  pieces  of  hardware . 


Bnrighti  The  evolution  of  vector  machines  is  an  exmaple  of  a 
hardware  development  that  can  be  exploited  by  developers  of 


packages  for  stiff  problems  but  J  don't  feel  that  our  needs  are 
particularly  special.  Hardware  capable  of  performing  standard 
linear  algebra  operations  is  all  that  would  be  required. 

Gears  Excepting  Kahan  (University  of  California  at  Berkeley) , 
no. 

Gellinas:  Such  interaction  is  extremely  important  for  the  future 
in  view  of  the  overriding  importance  that  will  become  attached  to 
linear  solvere  for  sparse  matrix  systems  which  will  be 
encountered  increasingly  in  ODE/PDE  applications.  Such 

interactions  will  be  even  more  crucial  as  multiprocessor 
computers  become  widely  used.  Critical  opportunities  for  great 
advances  in  applications  will  be  lost  if  software  development 
continue  8  to  languish  or  die^ae-has  been  the  g/enerajL  trend' — 
recently. 

Hindaarsh:  On  the  level  of  computer  arithmetic ,  there  hae  lately 
been  much  such  interaction ,  and  it  benefits  both  groups 
greatly.  On  higher  levels ,  notably  in  numerical  IDEs,  there  hae 
also  been  much  mutually  beneficial  interaction,  with  improved 
parallel/pipeline  computers ,  and  software  for  them ^  as 
results.  Stiff  ODEe  that  arise  from  PDEs  are  a  subset  of  that 
area. 


Kroghs  Little  interaction  in  the  past .. .IEEE  Floating  Point 
standard  is  an  exception  and  that  because  of  an  exceptional  man, 
V.  Kahan. 


Liniger:  I  don't  think  there  hae  been  much  and  I  doubt  vihether 
in  the  ODE  area  this  will  become  very  useful  becaue  of  the 
general* pur pose  nature  of  our  algorithms. 

Mirankers  Yes  (to  all  three  questione)m  The  development  of 
hardware  depends  on  problem  types  (data  types  and  operations). 


Pratt:  My  knowledge  ie  limited  to  having  to  structure  code  eo 

that  a  vector  proeeeeor  ean  be  employed ;  for  example ,  Gauee - 
Seidel  iteration  ie  better  (faeter)  than  Jacobi  iteration  for 
eolving  eyeteme  of  algebraic  equations,  but  G-S  ie  not 

vectorisable ,  while  Jacobi  iteration  ie,  eo  that  vectorized 
Jacboi  ie  faeter  than  G-S l 

Schiesser:  To  the  beet  of  my  knowledge,  there  hae  been  no 

eignifieant  interaction  between  hardware  developere  and  software 
developers  with  regard  to  stiff  problems .  Furthermore,  I  do  not 
think  there  will  be  such  interaction  between  the  large  mainframe 
manufacturers  and  people  who  work  with  stiff  ODEey  simply  because 
the  etiff  ODE  problem  is  not  important  enough  commercially  to 
warrant  special  computer  designs .  Perhaps  the  microcomputer 
manufacturere  will  find  the  problem  important  enough  to  justify 
special  designs,  but  I'm  not  sure  small  computers  will  ever  be 
good  for  solving  large,  stiff  ODE  problems  becuase  they  will  be 
compute-bound;  however,  parallelism  with  small  computers  may  be 
worth  considering . 

Shaapinex  I  have  not  observed  an  interaction  and  I  have  no 

particular  feelings  about  it .  So  far  I  have  not  noticed  hardware 

designs  calling  for  significantly  different  approaches .  This 
could  well  change  as  parallelism  is  exploited,  and  then  I  would 
have  to  get  involved.  Even  then  I  would  expect  to  continue 
trying  to  make  best  use  of  the  available  hardware  rather  than 
influence  its  design. 


QUESTION  3:  How  automatic  can  and  should  a  differential  equation 
solver  package  be  now  and  in  the  future?  What  advanceaents  are 
seen  in  the  near  and  far  terns;  how  significant  are  they? 

Bickart:  As  automatic  as  possible.  The  solver  built  into  the 
BP-34C  it  an  example  of  \Jhat  should  be  strived  for  in  the  more 
sophisticated  software  —  almost  complete  tolerance  of  user 
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ignorance •  Only  when  software  suspects  it  ie  not  handling  a 
problem  properly  should  it  demand  that  the  user  become  leee 
ignorant . 

Brennan:  Designers  should  be  aware  of  the  many  hidden  dangers  in 
totally  automating  a  differential  equation  solver  —  i.e.,  it  may 
not  be  wise  to  implement  software  that  requires  little  or  no 
attention  from  the  user,  I  currently  maintain  the  integration 
package  for  a  large  trajectory  simulation  program  (at  the 
Aerospace  Corporation),  By  a  specialised  input  language ,  users 
simulate  complex  trajectories  by  specifying  flight- dynamic  and 
physical  models  with  simple  key  words.  Since  the  differential 
equations  are  automatically  set  up,  the  users  may  not  even  know 
how  many  differential  equations  are  involved.  The  user  ie 
required  to  specify  the  type  of  integration  method  (Adams,  RK,  or 
BDF ;  fixed  or  variable  step)  although  this  requirement  could 
conceivably  be  automated,  too.  There  are  dangers  in  automating 
too  many  features  since  the  typical  user  fully  accepts  whatever 
the  computer  spills  out  as  the  correct  answer.,, 

Byrne:  How  portable  ie  the  first  issue.  I  can  visualise  an  ODE 
solver  that  would: 

(1)  select  machine  parameters, 

(2)  select  initial  step, 

(3)  advise  progress, 

(4)  switch  methods  (stiff,  nonetiff ) , 

<• 

(5)  pick  stepsise  dynamically, 

(6)  report  errors, 

(7)  graphics  driven, 

(8)  graphics  output,  with  soom-in ; 

1-6  are  here  now,  7-8  are  not  quite  here.  How  significant  ie  it 
to  look  ap  gas  kinetics  with  rates  of  10*0?  pretty  significant. 

Cash:  I  think  that  an  ODE  solver  should  be  as  automatic  as 

possible .  There  are  many  black-box  users  who  are  only  concerned 
with  obtaining  a  solution  to  their  problem  with  a  certain  number 


of  correct  digits ,  and  it  is  important  that  we  should  satisfy 
such  people*  There  are  numerous  advances  to  be  made  in  ODE 
software  —  Professor  Gear's  talk  outlines  many  of  these .  Many 
of  these  advances  will  be  very  significant  and  in  particularly  I 
feel  fl. y£b  control  of  global  truncation  error  for  stiff  ODEe  and 
automatic  stiffness  detection  to  be  most  pressing .  Problems  like 
the  numerical  solution  of  stochastic  ODEe  have  not  even  got  off 
the  ground l 

Celliers  The  more  that  can  be  made  automatic  the  better.  Keep 
in  mind  that  more  and  more  problems  are  no  longer  solved  by 
specialists  in  numerical  mathematics ,  but  rather  by  engineers  out 
in  the  field.  These  people  need  as  much  help  as  possible  to  get 
their  problems  solved  quickly  and  correctly.  Please  keep  in  mind 
the  gullibility  of  these  average  users.  They  believe  in  a  result 
as  soon  ce  no  error  message  is  printed  out.  Automation  helps  to 
make  sure  that  correct  answers  are  produced  if  at  all.  I  know 
that  this  opinion  is  about  18  0°  different  from  the  average 
attitude  of  a  mathematician .  The  reason  is  that  a  numerical 
mathematician  is  proud  of  solving  a  problem  as  efficiently  as 
possible .  Automation  included  in  the  algorithm  obviously  slows 
down.  However,  for  the  average  user,  it  is  entirely  immaterial 
if  a  solution  of  a  problem  requires  20  per  cent  more  computing 
time  if  in  return  he  gets  more  robustness .  Automation  helps  also 
in  tuning. 

Chens  From  a  user's  point  of  view,  the  more  automatic  and 
flexible,  the  better.  I  had  occasion  to  use  LSODE  for  the  first 
time  recently.  It  is  so  well  documented  and  easy  to  use  that  I 
was  successful  on  the  first  attempt ... 

Churchills  Automatic  solvere  are  of  very  little  interest  to 
me.  They  seldom  are  useful  for  real  problems.  Special  purpose 
methods  are  almost  always  mors  effective. . . 


Deuflhard:  •••Future  advancements: 

(1)  large  systems,  possibly  in  the  linear  algebra  part  of 
stiff  solvers, 

(2)  stiff/nonetiff  automatic  forth -  and  back- switching, 

(2)  differential-algebraic  equations  with  stiff  or  nonetiff 
ODE  part . 

Devooght:  My  preference  would  be  for  a  flexible  approach  where 

the  user  can  decide  what  option  to  take.  A  code  like  LSODA  which 
switches  automatically  between  stiff  and  nonstiff  methods  is 
certainly  useful  but  too  much  of  a  black  box  could  be  dangerous 
if  one  loses  means  to  critically  appraise  the  results • 

Bdsberg:  According  to  my  experience  much  of  the  software 

available  in  e.g.jf  MAG,  IMSL,  and  other  libraries  are  hard  to  use 
for  people  from  application  areas.  More  robustness  is  needed  and 
more  needs  to  be  done  on  the  etep'eise  regulation.  Perhaps  much 
software  is  designed  for  a  too  narrow  problem  class  (from  the 
mathematical  point  of  view). 

Enright:  The  package  should  match  the  user's  requested  accuracy 

to  the  accuracy  of  the  numerical  solution  in  a  method-independent 
way.  Although  we  do  not  have  this  yet,  it  should  be  possible  in 
the  near  future.  A  package  should  also  recognise  when  it  is 
inappropriate  and  report  this  to  a  user .  For  example,  a  nonetiff 
code  should  report  to  a  user  when  a  problem  is  stiff. 

Finlayson:  ...need  low -accuracy  ones  for  2-D,  3-D  elliptic 

PDEs • • • 


Gear:  Depends  on  applications .  Very  automatic  for  simple  usee, 
but  very  complex  problems  or  those  solved  repeatedly  will  require 
hand  tailoring  for  efficiency. 

Gallinas:  Automatic  solvere  can  and  should  compile  and  solve 
automatically  broad  classes  of  ODEs  and  PDEs  by  simple  user 


input 8 .  These  solvere  should,  provide  for  dynamic  scaling  of 
incommensurate  variables  and  for  a  choice  of  alternative  error 
norms •  The  significance  cannot  be  overstated  because  current 
practices  of  exerting  large,  frequently  redundant  efforts  on 
dedicated  computer  programs  for  each  new  application  are 
unacceptably  wasteful  of  both  computer  and  human  resources • 

Hindnarsh:  Levels  of  automation  are  continually  advancing  with 

research  and  experience •  Near-term  advancements  include 

automatic  method  selection  and  Jacobian  analysis  (we  have  a 
version  of  the  first  item) .  Far-term  automation  will  allow  a 
user  to  get  solutions  on  specifying  nothing  but  the  problem 
itself,  i.e.y  nothing  about  solution  method,  tolerances ,  etc.  S' 
This  will  impact  the  casual  users  greatly  by  reducing  their  selfiip 
time .  But  heavy  users  will  still  want  to  have  their  hands  on 
their  controls  for  optimal  efficiency. 

Hwang:  A  package  of  complete  hands-off  features  sometimes  may 

not  be  the  best  choice  when  computation  speed  is  of  prime 
concern.  this  is  especially  so  when  large-scale  dynamic  systems 
are  being  modelled.  With  a  limited  amount  of  user's  effort,  the 
solver  may  prove  to  be  considerably  more  efficient .  As  long  as 
ueer'e  interference  is  not/  annoying  and  tedious ,  a  ' semi¬ 
automatic '  package  is  perf ecij^accep table. 

Krogh:  I  believe  we  have  reached  the  point  where  the  software 

should  be  completely  automatic .  But  it  should  still  allow  the 
user  to  provide  information  about  the  characteristics  of  the 
problem  if  such  information  would  be  helpful.  I  believe  there 
are  still  significant  improvements  in  reliability  to  be  made. 
Routines  can  be  made  more  automatic  and  more  flexible . 
Efficiency  for  general  problems  can  probably  be  improved  at  least 
SO  per  cent,  with  much  larger  improvements  for  some  problems. 

Mattheij  and  Soderlind:  There  is  always  a  risk  that  general- 
purpose  solvere  tend  to  be  no-purpoee  solvere.  Today  there  exist 


very  sophisticated  general-purpose  codes ,  some  of  which  suffer 
from  being  too  integrated  in  the  sense  that  generality  prevents 
them  from  being  efficient  for  certain  applications .  An 
advancement  that  may  overcome  this  difficulty  would  be  to  develop 
highly  modular  ODE  solvere  so  that  suitable  applications  software 
can  be  obtained  by  the  change  of  a  driver  subroutine  or  a 
reconfiguration  of  subroutines  in  the  package.  Another  very 
important  improvement  over  existing  stiff  solvere  would  be  to 
have  more  built-in  reliability  checks ,  e.g.y'  to  monitor  the 
stability  of  the  differential  equation  (which  may  sometimes  be 
quite  different  from  that  of  the  difference  equation) .  In 
particular ,  robustness  is  important  for  codes  used  as  black 
boxes . 

O'Malley:  One  can  always  find  bisarre  problems  and 
counterexamples  to  ordinary  experience .  Thus,  the  need  for 
special-purpose  codes  will  remain.  The  aim  is  to  obtain  a 
differential  equation  solver  which  can  seldom  be  tricked.  One 
needs  tough  problems  to  challenge  all-purpose  packages  and  to 
suggest  improvements  of  them.  Substantial  confusion  now  ociure 
because  naive  users  like  me  don't  understand  what  the  TOL  setting 
means .  Much  progress  has  already  been  made,  but  user  reluctance 
to  blindly  accept  output  from  current  codes  is  healthy  and 
justified.  There  will  certainly  remain  plenty  of  advantages  for 
special  codes  for  many  kinds  of  restricted  problems • 

Petzold:  With  few  exceptions  a  differential  equation  solver 
should  be  as  automatic  as  possible .  The  reason  for  this  is 
mainly  to  relieve  the  users  of  the  solver  from  having  to  worry 
about  how  the  solver  works  as  opposed  to  how  beet  to  model  their 
problems .  There  are  now  solvers  which  diagnose  stiffness  and  even 
switch  to  the  most  efficient  methods  for  a  given  problem,  but 
there  are  other  difficulties  which  are  not  diagnosed  very  well  by 
the  current  codes .  For  example,  it  would  be  useful  to  know 
whether  a  etiff  code  is  inefficient  (or  faile)  because  of  an 
inaccurate  Jacobian  matrix  or  because  of  a  poorly  conditioned 


Jacobian  or  too  stringent  error  tolerances  or  frequent 
discontinuities  in  some  derivative  of  the  solution.  At  present , 
the  diagnostics  which  are  provided  by  stiff  solvers  are  nowhere 
near  as  good  as  for  the  nonstiff  codes. 

Seider  and  White  III:  ...We  envision  a  broadening  in  the  scope 
of  systems  to  be  integrated ,  including  systems  with  (1) 
discontinuities  and  (2)  constraints  on  the  variables .  We  also 
envision  improvements  that  produce  a  smooth,  differential  result, 
as  required  by  parameter  identification  algorithms  that  require 
derivatives  without  scatter... 

Shanpine:  Wherever  possible  they  should  be  made  automatic .  If 
additional  information  on  the  part  of  the  user  could  affect 
decisions  in  an  important  way,  the  user  should  be  able  to 
influence  the  computation.  I  foresee  codes  which  are  rather 
succeeef ull  regardless  of  the  type  —  stiff  or  not.  This  will  be 
a  great  convenience  for  users  and  may  result  in  a  net  gain  in 
efficiency.  Perhaps  more  important  is  run-time  monitoring  of  the 
computation  to  ascertain  that  the  code  being  used  was  properly 
selected  for  the  problem  at  hand  and  is  being  properly  applied. 

Watts:  It  is  an  important  goal  to  strive  for  improving  the 
robustness  and  capabilities  of  present-day  ODE  software .  We 
should  continue  to  provide  packages  which  can  automatically 
handle  difficulties  which  arise  frequently  —  of  course,  research 
and  current  state-of-the-art  techniques  may  not  be  sufficiently 
well  advanced  to  completely  relieve  the  user  of  some  burdens. 
Software  which  automatically  detects  and  copes  with  stiffness, 
type- insensitive  software,  will  be  the  most  important  new 
development.  We  will  also  see  capabilities,  highly  oscillatory 
problems,  differential-algebraic  systems,  and  low  -  accuracy 
solution  requirements  (such  as  with  real-time  or  tabular  data 
computations) . 


Wendt:  It  seems  to  me  that  initial- value  problems  are  being 
beaten  to  death .  In  many  combustion  kinetics  problems ,  the  1960s 
software  of  the  NASA  kinetics  program  ,is  more  effective  than 
subsequent  developments  such  as  EPISODE .  A  moderate  continuing 
effort  to  improve  automatic  solvers  may  be  useful  —  but  there 
are  many  more  important  problems  involving  stiffness  in  BVPs  that 
still  require  significant  effort . 

QUESTION  4:  Is  theory  for  the  Batheaati.es  of  confutation 
coapleaenting  well  software  developaent  needs  of  today  and 
toaorrow?  What  are  the  aajor  needs  and  what  are  the  prospects 
for  filling  these? 

Bickart:  To  the  first  question ,  my  answer  is  yes .  To  the  second 
question ,  my  answer  is  colored  by  my  relationship  to  electronic 
circuit  analysis  and  design;  we  need  an  ever  growing  arsenal  of 
tools  for  the  analysis  of  large  systems  —  where  large  is  always 
getting  larger  in  people's  minds  —  of  algebraic  equations . 

Byrne:  Most  theory  supports  linear  ODEs  or  slowly  varying 
nonlinear  ODEs .  We  left  them  behind  ten  years  ago.  Need  good 
work  on  error  analysis ,  step  selection ,  method  switching . 
Prospects  are  slim,  not  many  theoreticians  have  ever  seen  a  real 
problem  and  universities  won't  support  code  work,  in  my  opinion. 

Cash:  There  has  always  been  quite  a  wide  gap  between  theory  of 
computation  and  software  development .  It  is  important  that  they 
should  come  closer  together  but  it  is  hard  to  see  this  in  the 
near  future. 

Cellier:  Principally,  yes.  I  feel  that  a  stronger  interaction 
between  numerical  mathematicians  and  people  from  computer  science 
(that  is:  software  engineers)  may  be  fruitful.  However,  even 
this  interaction  takes  place  more  and  more  in  that  some  people 
(like  Alan  Hindmarsh  or  Cleve  Holer)  are  really  both  at  the  same 
time » • • 


Churchill:  Theory  hae  never  contributed  significantly  to 

numerical  computation .  Almost  all  advances  have  come  from 
practitioners .  I  doubt  that  this  will  change . 

Deuflhard:  Theory  is  still  open  in  extrapolation  methods , 

implicit  RK  methhods ,  and  stability .  There  is  an  unclear  risk 
whether  implicit  RK  methods  or  stability  will  help  software 
developments  --  at  least  unclear  to  me . 

Gellinas:  There  is  some  complementation  between  theory  and 

software  in  some  areas  where  certain  combinations  of  research 
talent  have  been  assembled  and  when  the  right  combinations  of 
individuals  decide  to  communicate  closely  and  collaborate .  There 
is  a  great  need  for  supportive  theory  in  PDE  convergence  and 
stability  areaeM  particularly  for  nonlinear  systems.  Prospects 
for  filling  these  needs  in  the  short  term  are  not  too  good: 
theorists  frequently  do  not  understand  application  needs  and 
scientific  practitioners  frequently  ignore  theorists.  Perhaps  we 
can  do  beter  over  the  long  term. 

Bindaarah:  The  majority  of  places  titers  theory  is  done  still 

have  a  low  regard  for  software ,  and  vice  versa.  but  the 
exceptions  are  growing  in  number  and  impact .  Increased 
communication  between  both  types ,  and  also  between  them  and  those 
doing  applications ,  is  needed.  The  biggest  problem  is  for 
theoreticians  to  learn  of  and  addre i »  the  features  of  realistic 
application  problems . 

Krogh:  When  developing  software ,  I  have  usually  found  that  the 
theory  people  did  not  provide  what  wae  needed.  What  theory  I 
needed ,  I  needed  to  do  for  myself.  There  are  of  course  a  very 
few  exceptions .  Major  needs  (some  hope  of  being  filled)  are: 

(1)  cheap  and  reliable  global  error  estimation , 

(2)  good  algorithms  for  boundary-value  problems  with  very 
strong  boundary  layers t 


(2)  effective  tests  for  precision  requests  that  are  too 
stringent  for  the  arithmetic  being  used, 

Liniger:  The  problem  is  that  the  theory  usually  limps  behind  the 
software  development  and  by  the  time  the  theory  points  out  new 
algorithms  and  strategies ,  the  ( software )  adopted  earlier  based 
on  heuristics  have  become  so  widely  used  that  it  becomes  very 
hard  to  convince  people  that  something  new  and  perhaps  better  is 
around. 


Mattheij  and  Soderlind:  There  is  still  a  significant  gap  between 
theory  and  practice .  In  terms  of  stiff  solvers ,  many  codes 
contain  'tuned'  strategies  and  approaches  that  have  not  yet  been 
justified  theoretically .  Thus  the  effects  of  variable  steps  on 
multistep  integration  procedures  are  not  fully  understood •  Some 
of  the  major  needs  for  theoretical  improvement  include: 
robustness ,  stepei ze  strategies ,  global  error  estimation  and 
automatic  detection  of  stiffness .  Large  problems  and 
differential-algebraic  systems  also  need  further  investigation. 


Miranker:  Yes.  A  major  need  is  to  make  the  computer  itself  a 
scientific  instrument .  One  computes  but  the  operations  which  a 
computer  executes  are  not  known  to  the  user ... .Numerical  analysis 
is  essentially  independent  of  computers .  This  is  a  concealed  but 
treacherous  gap  and  moreover,  it  can  now  be  closed . 


O'Malley:  I  feel  that  current  software  for  boundary- value 
problems  is  woefully  inadequate .  Adaptive  mesh  generation  is 
essential •  nonlinear  problems  require  much  more  practical 
experimentation  and  theory .  In  the  singular  perturbations 
context,  careful  numerical  experimentation  can  motivate  the 
necessary  theory  and  vice  versa. 


Sch lesser:  My  impression  is  that  there  is  really  very  little 
useful  exchange  between  the  people  developing  theory  and  those 
developing  codes.  We  enjoy  being  with  each  other  and  drinking 


coffee  at  the  bveake  between  papers ,  but  the  useful  exchange  of 
information  eeeme  limited .  I  could  not  help  but  notice  the 
number  of  theoriete  who  left  the  room  when  an  applications  paper 
wae  presented ,  and  visa  versa . 

Seider  and  White  III:  We  need  better  theory  for  the  stability 
analysis  of  nonlinear  systems ,  for  improving  estimates  of  the 
global  truncation  error,  and  for  adjusting  the  etepeise  and  order 
of  accuracy .  The  prospects  of  meeting  these  needs  are  excellent 
in  the  long  term,  but  not  promising  in  the  immediate  future . 

Shaapine:  Many  fundamental  issues  need  attention •  For  example, 
variable- order  codes  are  of  the  greatest  importance  but  the 
theory  describing  them  is,  at  beet,  fragmentary.  I  happen  to  be 
looking  at  the  neglected  areas  of  the  effect  of  changing  etepeise 
and  of  local  error  estimation  --  a  lot  needs  to  be  done . 


QUESTION  5:  What  are  a  few  of  the  aost  important  application 

areas  that  deaand  far  sore  improved  stiff  solution  techniques? 

Bow  do  you  interpret  'aost  important'  —  by  nuaber  of  users, 
number  of  computer  hours,  the  need  for  the  solution  (say  for 
national  defense)?  Of  these  applications,  how  many  are  difficult 
because  of  the  size  or  number  of  stiff  sets  to  be  solved? 

Bickart:  Dynamic  processes  described  by  other  than  ordinary 

differential  equations,  such  as  voltera  integral  equations, 
functional  differential  equations,  etc.  At  the  present  these 
tend  to  take  too  much  computer  time  for  their  solution . 

Brennan:  At  the  Aerospace  Corporation ,  we  want  to  solve  a 

differential-algebraic  system  of  nilpotency  three,  but  there  is 
no  software  or  known  algorithm  which  can  solve  such  systems *  By 
solving  this  system,  we  could  generate  feasible  state  vectors 
during  a  trajectory  from  which  a  successful  reentry  of  the  space 
shuttle  could  be  initiated •  We  have  modified  the  problem  to 


reduce  the  nilpotency  to  two ,  eo  we  can  obtain  a  solution  ueing  a 
modification  of  GEAR1 e  algorithm .  Initialising  the  variables  to 
be  consistent  is  also  a  problem •  Software  capable  of  solving 
general  DAE  systems  (and  initialising  the  variables)  would  be 
very  useful  in  all  prescribed  path  control  problems . 

Byrne:  (1)  Chemical  kinetics ,  (2)  ensyme  kinetics,  (3)  circuit 
design*  Chemical  kinetics  is  part  of  reactor  design,  process 
design,  air  pollution  studies,  reactive  fluid  flow  —  including 
combustion*  I  do  not  know  how  many  users  are  concerned  -- 
several  thousand,  I  would  guess * 

Cash:  I  feel  that  the  numbers  of  users  and  the  need  for  a 
solution  are  the  most  important  reasons*  However,  if  there  are 
ueee  for  an  application  area,  I  also  feel  that  the  contribution 
made  to  the  theory  is  also  of  great  importance  when  new 
techniques  are  developed.  There  ie  also  a  need  to  take  a  special 
look  at  large  eyeteme  arising  from  PDEe  where  things  like  storage 
of  the  Jacobian,  which  is  perfectly  OK  for  small  systems,  may  not 
be  possible . 

Cellier:  In  fact,  most  difficult  ' stiff '  problems  result  from 
large  systems.  In  particular ,  parabolic  and/or  hyperbolic  PDEe 
translated  into  sets  of  ODEe  by  the  method- of -lines  approach  are 
typical  candidates  of  difficult  problems .  Parabolic  PDEe  result 
almost  always  in  stiff  sets  of  ODEe.  Hyperbolic  PDEe  result  in  a 
different  class  in  that  some  of  the  eigenvalues  of  the  Jacobian 
tend  to  lie  close  to  the  imaginary  axis  and  be  complex.  For  this 
reason ,  the  method-of-lines  approach  is  known  to  be  better 
applicable  to  parabolic  PDEe  than  to  hyperbolic  PDEe.  I  suspect 
that  this  commonly  stated  sentence  is  not  true.  The  method-of- 
lines  could  well  be  applied  to  hyperbolic  problems  if  appropriate 
numerical  integration  techniques  for  this  class  of  problsme  would 
be  developed  --  and  I  don't  tee  any  reason  why  this  should  be 
impossible .  Up  to  now,  such  algorithms  do  not  exist  or  have  at 
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least  not  been  implemented  in  a  general Ipurpo a e  package .. .Typical 
areae:  reactor  kinetics ,  helicopter  simulation  (stiffness  of  the 
blades),  and  many  more.  J  do  not  think  that  the  number  of  users 
is  really  the  important  issue.  Humber  of  computer  hours  is  often 
a  key  point.  However ,  for  some  of  the  problems  there  exist 
alternative  solutions  ( e.g .?  a  piece  of  hardware  simulating  the 
behaviofr  in  some  sense).  Some  problems  (like  reactor  kinetics) 
are  key  problems ,  because  it  is  too  dangerous  to  build  these 
systems  without  knowing  pretty  well  in  advance  what  is  going  to 
happen. 

c  r- 

Chua:  These  areae  include  the  variable-retep  integration  of 
differential-algebraic  equations  and  the  location  of 
discontinuities .  They  are  important  because  most  large-scale 
practical  problems  can  be  modelled  by  a  set  of  differential- 
algebraic  equations  containing  frequent  discontinuities . 

Churchill:  Split  boundary- value  problems ,  unstable  behavior , 
multiple  stationary  states ,  recycle  problems ,  partial 
differential  equations ,  and  integro-diff  erential  equations . 
Computational  requirements  and  numbers  of  users.  The  inherent 
behavior,  not  the  number  of  equations ,  is  the  primary  source  of 
difficulty. 

Deuflhard:  (1)  Large  chemical  kinetics,  (2)  large  circuit 
design,  (2)  inverse  problems  in  chemistry  and  electronics,  (4) 
many  —  component  systems;  most  important:  contribution  to 
progress  outside  mathematics,  mainly  in  sciences . 

Devooght:  My  only  experience  with  stiff  prob/eme  concerns 
nuclear  reactor  kinetics .  In  this  field  the  situation  is  rather 
good  because  ad  hoe  methods  have  been  devised  taking  into  account 
the  specific  form  of  the  differential  system.  My  secondary 
experience  concerns  the  integration  of  the  Liouville  equation  for 
the  density  matrix  in  quantum  mechanics .  In  this  case  the 
eigenvalues  are  widespread  but  close  to  the  imaginary  axis  and 


BDF  methods  are  in  this  reepeet  very  deficient •  The  integration 
can  be  very  time  consuming  and  the  use  of  a  good  program  would 
help  atomic  physics  a  great  deal, 

Dev:  There  is  still  a  long  way  to  go  before  we  get  ODE 
integrations  that  can  interface  satisfactorily  to  PDE  software 
based  on  the  method  of  lines.  The  problem  is  selecting  ODE 
integrations  that  can  correctly  match  the  stability  of  the  PDE, 

Bdsberg:  Chemical  kinetics  --  in  which  case  the  kinetics  is  only 
part  of  a  larger  model  including ,  e,g,f  flow ,  diffusion t  thermal 
exchange ,  etc •  I  think  model  building  with  chemical  kinetics  is 
of  great  importance  for  environmental  research ,  e.g.f  atmosphere 
chemistry ,  combustion t  pollution  processes ,  etc, 

Enright:  Solving  large  systems  of  loosely  coupled  stiff 
equations  is  an  area  where  improvements  are  required.  This  is  an 
important  area  since  many  problems  arise  in  a  variety  of  areas 
and  they  are  now  expensive  to  solve.  It  is  very  likely  that  the 
special  structure  they  possess  can  be  exploited, 

Finlayson:  ,, .time-dependent  finite  element  codes  —  criterion 
is  computer  hours. 

Gear:  Highly  struetursd  large  problems  arising  from  PDEs ,  large 
systems  from  networks ,  VLSI  modelling,  (The  basis  is)  computer 
time, 

Gellinaa:  Oscillatory  systems,  I  interpret  ’ most  important *  in 
the  context  of  breaking  through  important  scientific  problems 
which  are  presently  unresolved  because  of  inadequate  numerical 
solution  methods, 

Bindnarsb: 

(1)  PDE-based  problems ,  especially  in  2-D  and  S-D,  Sine  is 

the  main  obstacle.  Importance  is  due  to  number  of 
problems ,  computer  cost,  and  need. 


(2)  Systems  with  high-frequency  oscillations  where  only  an 
envelope  is  desired .  Size  usually  not  big .  Importance 
due  to  numbers  and  cost . 

(3)  Systems  with  discontinuities  (switches,  etc .).  Usually 
large  size,  but  size  is  not  the  problem .  Importance  is 
due  to  numbers  and  cost . 

Bwang:  Computer  simulation  of  complex  chemical  reaction 

processes  (e.g.y  CH  ^  oxidation),  eepecialy  at  the  initial  stage 
where  sensitivity  analysis  of  the  mechanistic  models  with  respect 
to  initial  reactant  concentration  and  uncertainties  in  rate 
coefficients  is  desired .  Typically,  these  models  involve 
~50  components  and  hundreds  of  parameters .  The  rate  equations 
are  very  stiff  (stiffness  ratio  could  easily  reach  1 08  or 
higher ).  Solutions  to  such  problems  are  important  for  a  number 
of  reasons:  energy  conservation ,  environmental  protection,  new 
energy  resources,  etc . 

Miranker:  Chemical  reactions,  large  circuits,  satellites, 

weaponry . 

O'Malleys  Large-scale  problems  are  important .  Further,  the  use 
of  aggregation  methods  and  other  hierarchical  techniques  which 
allow  one  to  build  increasingly  complicated  models  of  physical 
problems  are  essential.  Chemical  kinetics  provide  a  very 
important  applications  area.  One  needs  to  figure  out  at  what 
level  detailed  kinetics  are  necessary,  as  well  as  when 
experimental  detail  is  needed.  The  meaning  of  various  steady- 
state  models  also  needs  clarification,  as  well  as  their  use  in 
computational  procedures . 

Petsold:  I  think  one  of  the  most  important  application  areas 

involves  the  solution  of  relatively  small  systems  of  equations 
with  modest  accuracy  repeatedly  and  inexpensively ^  for  example, 
when  the  operator- splitting  technique  is  used  for  solving  IDEs, 
there  often  results  a  system  of  ODEe  which  must  be  solved  at  any 


mesh  point  and  at  every  time/step.  It  ie  eeeential  that  thie  be 
done  ae  quickly  ae  poeeible ,  or  else  the  computation  becomes  very 
expensive ,  Thie  situation  occurs  in  several  diverse  areas  of 
application ,  including  structural  deformation  problem  and 
combustion  modelling , 

Pratt:  In  my  field,  no  one  ie  solving  finite-rate  chemical 
kinetics  in  gas  turbine,  piston  engine,  or  power  generation 
furnace  simulation  models  because  GEARB  ie  not  fast  enough ,  I 
don't  (know  of)  anyone  but  myself  (who)  is  attacking  that  problem 
seriously  at  the  moment , 

Schiesser:  The  recent  developments  in  ODE  integrators  have  had  a 
major  impact  on  the  computer-based  solution  of  IDEs,  and  I  think 
thie  will  continue ,  In  fact ,  I  will  go  out  on  a  limb  and  say 
that  the  numerical  method  of  lines  has  the  potential  for 
replacing  most  of  the  classical  methods  for  solving  IDEs ,  The 
importance  of  PDEs  seems  evident,  and  I  think  we  will  see  a 
growing  use  of  PDE  applications  in  industry  ae  well  as  in 
academic  research , 


Seider  and  White  III:  Improved  integration  methods  are 

definitely  needed  for: 

(1)  Systems  that  pass  through  oscillatory  regimes  into  the 
explosion  mode,  even  for  short  periods  of  time ;  for 
example,  in  combustion  and  in  limit  cycles , 

(2)  Systems  that  involve  combined  integro-diff  erential 
equations,  as  in  heat  transfer  problems  with  radiation, 
conduction,  and  convection, 

(2)  Systems  that  are  multidimensional;  for  example,  3-D 
natural  convection, 

(4)  Systems  involving  determination  of  parameters  to  give  a 
close  fit  to  experimental  data,  especially  when  the 
integration  results  are  very  sensitive  to  small  changes 
in  the  parameters  or  where  discontinuities  are 
encountered  in  the  objective  function  with  changes  in 
parameters • 

*  r-  o 


Shaapine:  I  am  concerned  about  the  convenience  and  reliability 
of  eolution  —  all  eolutione  would  benefit  from  improvements  in 
theee  areas .  Comparison  with  the  eolution  of  nonetiff  problems 
makes  this  clear  although  the  latter  would  also  benefit  from 
research * 

Thompson:  Various  simulation  packages  are  starting  to  see  use  in 
the  eolution  of  really  sophisticated  problems ,  e.g.y  in  the 
nuclear  industry •  As  this  trend  continues,  deficiencies  in 
current  methods  ( e.g *,'  BDF)  will  become  more  apparent •  As  I  see 
it,  a  crying  need  will  surface  for  stiff  eolution  techniques 
which  better  take  into  account  the  structure  of  large  problems 
(e*g*J  sparsity,  subsystems  with  different  characteristics, 
partitioning,  and  global  error  control) • 

Watts:  Chemical  kinetics,  elasticity-plasticity  mechanioal 
modelling,  PDE  modelling  by  ODEe,  nuclear  reactor  analysis .  Each 
of  the  criteria  -  number  of  users,  expense,  and  need  for  solution 
~  defines  a  perfectly  acceptable  'most  important'  label •  The 
PDE  modelling  by  ODEe  leads  to  the  largest  class  of  equations  to 
be  solved • 

Wendt:  Boundary-value  problems  based  on  occurrences  in  nature, 
computer  hours  and  storage  required,  need ;  combustion,  energy, 
catalysts,  etc •  Size  is  a  most  important  factor  in  the  above * 

QUESTION  6:  Can  you  cite  examples  where  the  stiffness  is  a 
necessary  part  of  the  aodef  i . e ./  applications  where  the  nature 
of  the  stiffness  directly  influences  the  objectives  of  the 
modeller? 

Byrne:  Nonlinear  models  in  chemical  kinetics •  If  it  isn't 
stiff,  it  isn't  stable* •• 


Cash:  No  l 


Cellier:  There  exist  some  problems  in  the  literature  consisting 
of  a  fast  and  slow  subsystem  (especially  in  control  literture) • 
Although  only  the  slow  system  response  is  important  for  the  user, 
it  is  influenced  by  the  fast  modes  as  well .  Some  of  the  slow 
frequencies  disappear  if  the  fast  subsystem  is  left  out ... 

Chen:  •••A  reactor  with  vastly  different  time  scales  linked  in 
series  is  an  example  where  stiffness  is  an  inherent  property  of 
the  entire  system . 

Chua:  No. 

Deuflhard:  "Parameter  identification  in  chemical  kinetics  or 
electronics  does  require  measurements  in  both  the  transient  and 
the  stationary  phase  of  the  process .  Automatic  simulation  of 
mixed  systems  with  fast  and  slow  processes.  Method  of  lines  for 
parabolic  PDEe. 

Dove:  There  is  large  class  of  problems  for  which  the  ODEs  of 
chemical  kinetics  must  be  integrated ,  often  in  conjunction  with 
ODEs  or  PDEs  representing ,  for  example ,  transport  processes  in 
gases  or  gas-surface  interactions .  Examples  abound  in  the 
chemical  industry.  In  many  eases ,  these  systems  of  equations 
must  be  simultaneously  solved  at  a  very  large  number  of  points 
over  a  mesh  in  3-D  space.  The  main  factor  in  the  often  very  high 
cost  of  solving  such  problems  is  that  of  solving  the  large  stiff 
systems  of  chemical  kinetic  equations.  Thus  there  is  great 
interest  in  simplifying  such  systems  to  their  bare  essentials , 
and  in  reducing  the  cost  in  other  ways.  Sensitivity  analysis 
plays  a  very  important  role  in  such  problems.  There  is,  in  my 
view,  a  potentially  very  large  role  in  such  areas  as  computer 
design  combustion,  e.g.f  of  automobile  engines. 


Edsberg:  Chemical  kinetics.  The  use  of  e.g.r  the  steady-state 
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approximation  in  order  to  eliminate  stiffness  may  be  disastrous 
for  following  the  correct  solution  trajectory ,  see  e.g.^TRITA- 
NA-8 OOS ,  example  2,  oxidation  of  propane ,  where  iterations 
converge  to  wrong  solution  trajectory  if  the  reduced  problem  is 
solved. 

Knright:  Stiffness  is  inherent  in  any  model  where  transient 

behavioftr  can  affect  the  overall  system  behaviour . 

c 

Gear:  Some  problems,  e.g.f  relaxation  oscillators ,  are  limits  of 
stiff  systems  as  stiffness  approaches  infinity .  Without 

knowledge  of  (the)  stiff  form ,  the  behavior  of .the  limit  problem 
can't  be  determined. 

u y 

Gellinas:  Tee.  Extreme ,  nonequilibrium  behaviour  in  most 
branches  of  the  physical  and  chemical  sciences  (e.g./ plasma 
physics,  radiative  systems,  interactive  fluids,  combustion,  and 
most  'strongly  driven'  systems )  has  frequently  remained  out  of 
the  reach  of  modellers  really  understanding  essential 
physical/ chemical  processes  because  sufficiently  accurate, 
highly  resolved  numerical  solutions  of  the  defining  PDEs/ODEs 
could  not  be  attained. 

Bindaarsh:  Most  chemical  kinetics  problems  are  necessarily  stiff 
if  the  model  is  to  be  accurate .  Steady-state  assumptions  are  of 
unreliable  accuracy  and  efficiency .  We  are  at  a  point  in  the 
quality  of  stiff  solvere  where  the  modeller  should  EOT  be 
influenced  by  the  pretence  or  absence  of  stiffness  in  forming  the 
model  —  only  by  its  accuracy.  I  have  been  solving  some  oil 
shale  particle  models  where  NOT  using  esa  gave  solutions  over  400 
times  faster  than  the  best  one  could  do  with  the  assumptions,  and 
also  solved  the  harder  cases. 

Linigart  Regions  of  rapid  transitions  in  semiconductor 
equations,  models  in  hyperbolic  PDEs,  chemical  kinetics . 


O'Malley:  Power  system  modellers  cite  an  example  where 
traditional  reduced-order  models  lead  to  mechanical  failure ,  but 
where  including  highly  oscillatory  transients  circumvent  the 
failure  and  explain  the  earlier  difficulty . 

Petzold:  This  is  certainly  the  case  for  combustion  modelling , 
and  the  modelling  of  control  systems. 

Pratt:  If  stiffness  is  a  necessary  part  of  the  model  —  that  is , 
if  you  wish  to  resolve  the  solution  on  the  small  time  scales  — 
then  the  problem  is  only  wasted  effort  on  computing  the  slow 
modes... is  the  problem  then  properly  called  ’stiff1? 

Schiesser:  As  the  grid  spacing  in  PDE  solutions  becomes  smaller , 
the  classical  theory  indicates  that  the  resulting  ODEs  should  be 
stiffen.  However ,  we  seem  to  have  some  evidenc  that  with 
adaptive  regridding ,  and  with  the  use  of  higher-order 
approximations  for  the  spatial  derivatives ,  this  may  not  be  the 
case.  I  think  this  is  still  an  unanswered  question  that  warrants 
some  research.  Also ,  the  effect  of  nonlinear itiee  on  the 
apparent  stiffness  of  ODEs  is  an  important ,  unaewered  question . 
We  find  computer  run  times  to  be  extremely  sensitive  to  small 
variations  in  nonlinearities . 

Seider  and  White  Most  systems  stiffen  as  they  stabilise  or 
approach  a  steady  state.  In  many  eases  the  model  cannot  be 
easily  simplified  as  stiffness  sets  in,  and  stiffness  is  a 
necessary  part  of  the  model .  In  some  cases ,  it  is  possible  to 
simplify  the  model  as  the  system  stiffens ,  without  loss  of 
accuracy,  to  reduce  |x|--w  and  stiffness  (see,  for  example,  the 
fluidised-bed  reactor  model  in  our  paper).  Limit  cycles,  with 
regular  oscillations  over  large  time  segments ,  are  examples  of 
systems  that  cannot  be  easily  simplifisd  when  stiffness  sets -in. 
These  systems  stiffen  periodically  and  model  reduction  would  not 
apply  at  all  times  following  the  first  onset  of  stiffness .  In 


these  cases,  it  seems  impractical  to  periodically  alter  between 
models  . 

Thompson:  Examples  abound.  Those  with  which  I  am  moot  familiar 

s  . 

involve  simulation  of  nuclear  steam  systems y**  in  which  the 
treatment  of  kinetics  is  often  of  paramount  importance . 

Wendt:  Detailed  combustion  kinetics .  Remove  the  factors  causing 
stiffness  and  you  have  thrown  out  the  baby  with  the  bathwater . 

/ 

QUESTION  7:  Do  you  see  an  advant^e  to  considering  the  inter¬ 
actions  of  aodel  identification#  parameter  estivation#  and 
solution?  Be  as  specific  as  you  can  and  please  cite  any 
literature  in  this  area  of  which  you  are  aware. 

Byrne:  Suppose  a  reaction  mechanism  for  a  system  is  postulated 

for  a  general  temperature  range .  Laboratory  and  literature  data 
can  then  be  used  to  develop  a  preliminary  set  of  parameters  for  a 
generalised  Arrhenius  reaction  form.  The  kinetics  model  can  be 
solved  (stiff  ODEs)  to  obtain  a  set  of  computed  data.  The 
*:  computed  data  is  then  matched  against  the  observed  data  for  one 
or  more  final  (product)  species .  The  parameters  for  the 
reactions  can  then  be  adjusted  by  an  algorithm  to  get  new 
rates.  The  system  can  be  solved  again ,  etc.  until  the  computed 
and  observed  data  match  up.  If  the  match-up  is  awful,  then  so 
might  be  the  proposed  model .  I  suppose  the  variance- covariance 
matrix  could  provide  some  idea  of  goodness .  Usually  not  much 
helps  unless  the  fit  is  right  on. 

Cellier:  It  is  indeed  realised  meanwhile  that  a  pure  simulation 

tool  is  not  that  useful ,  as  often  no  appropriate  models  are  known 
(in  particular  in  soft  sciences  --  so  called  'ill-defined 
systems').  Only  very  recently  some  attempts  have  been  made  to 
automate  the  model  building  and  model  validation  business*  The 
research  is  hers,  however^  still  far  from  an  answer.  A  good 
review  may  be: 
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Vansteenkiste,  G.C.f  and  J.  Spriet:  'Computer  Assisted  Modelling 
of  Ill-Defined  Systems'  in  Progress  in  Modelling  and  Simulation, 
F.E.  Cellier,  ed.,  Academic  Press  (1982). 

In  fact,  the  first  half  of  this  book  deale  with  modern  ieeuee  of 
computer-assistance  in  modelling .  The  second  half  deals  with 
modern  issues  of  computer  simulation . 

Churchill:  These  interactions  should  be  considered .  However , 
parameter  estimation  without  consideration  of  the  uncertainty  of 
the  input  is  idle .  See  Churchill ,  'The  Interpretation  and  Use  of 
Rate  Data,'  Hemisphere,  Washington,  D.C.  (1979). 

Deuflhard:  numerical  parameter  estimation  techniques  should  also 
be  able  to  monitor  the  model  in  terms  of  sensitivities  of  the 
model  parameters .  (see  forthcoming  proceedings  volume:  P. 
Deuflhard,  E.  Hairer  (ed):  Numerical  Treatment  of  Inverse 
Problems  in  Differential  and  Integral  Equations  (to  appear  in 
spring  1983). 

Dove:  The  use  of  sensitivity  analysis ,  which  deals  with  the 
interaction  of  the  form  of  the  model ,  the  magnitudes  of  the 
parameters,  and  the  effects  of  these  factors  on  the  solution,  is 
absolutely  crucial  to  problems  in  which  chemical  kinetics  are 
important .  There  is  a  real  need  for  professionally  developed 
software  packages  in  this  area .  We  have  had  to  write  our  own,  so 
far /  Leads  to  much  of  the  literature  in  this  area  can  be  located 
under  the  names  of  H.  Rabitz  and  K.E .  Shuler .  The  topic  is  also 
important  for  the  * inverse  problem '  where  one  is  given  data  on 
lit)  and  needs  to  find  information  about  the  underlying  ODEs . 
For  example,  given  experimental  data  on  a  chemical  kinetice 
problem,  what  do  those  data  tell  ue  about  the  form  of  the  model 
and  about  its  parameters?  There  is  already  some  software  to  deal 
with  this,  e *g . j Curtis ' s  CHEKMAT,  but  in  my  view  a  lot  more  work 
ie  needed.  For  example,  very  often  the  data  available  do  not 


enable  a  unique  determination  of  all  of  the  parameters  —  or  even 
of  any  of  them ,  Nevertheless,  one  would  like  to  have  a  way  of 
deciding ,  and  expressing,  the  constraints  which  those  data  place 
on  the  possible  values  of  the  parameters , 

Bdsberg:  Of  course  it  is  important  to  work  interactively  with  a 

model,  not  only  to  solve  one  initial-value  problem  but  to  have 
also  a  qualitative  idea  of  how  the  model  behaves  with  respect  to 
structure,  parameters,  initial  values ,  etc ,  I  (almost)  agree 
with  Aris  in  hie  book  ' Introduction  to  the  analysis  of  Chemical 
Reactors,'  Prentice  Hall  1965,  pp,  225:  'It  cannot  be  too 
strongly  emphasised  that  it  is  folly  of  the  first  magnitude  to 
approach  the  computer  without  first  having  as  good  a  feel  as 
possible  for  the  structure  of  the  problem ,' 

Pinlayson:  This  is  a  very  important  area  in  engineering ,  Rarely 

do  we  know  the  parameters  well  enough  to  justify  excellent 
mathematics  solutions,  but  we'd  like  to  be  close , 

Hindaarsh:  I  have  no  experience  with  model/parameter 

identification  problems .  But  at  present,  some  interaction  seems 
wise •  Solution  accuracy  requests  should  be  as  loose  as  possible 
when  large  model  adjustments  are  being  made ,  Methods  and  codes 
for  calculating  sensitivities  with  respect  to  parameters  are 
useful  here,  and  this  is  an  active  area • 

Liniger:  lee,  I  think  these  questions  are  very  important  in 

simulation,  e,g,tj[/  in  chemical  kinetics f  it  is  very  hard  to 
evaluate  a  model /  even  qualitatively 'j  if  one  has  little  or  no 
information  about  the  rate  constants •  The  solution  may  lie  in  a 
completely  different  ball  park  if  those  constants  are  off •  < 

O'Malley:  Certainly,  Not  enough  talented  mathematicians  and 

engineers  have  faced  the  tough  problem  of  parameter  estimation. 
This  intermediate  link  is  critical  to  any  such  effort. 


Petzold:  I  think  there  ie  definitely  an  advantage  to  considering 
these  interactions  *  For  example ,  parameter  estimation  often 
involves  the  solution  of  several  problems  which  differ  from  each 
other  very  little .  This  structure  can  sometimes  be  taken 
advantage  of  to  speed  the  whole  process .  Parameter  estimation 
procedures  could  also  benefit  from  having  solvere  which  produce 
solutions  that  have  a  smooth  (or  nearly  so)  behavior  with  respect 
to  changes  in  initial  conditions  and  other  parameters . 

Schiesser:  Parameter  estimation  and  model  identification  of  PDE 
systems  will  become  increasingly  important  in  industrial 
applications  and  will  serve  as  an  important  link  between  theory 
and  experiments .  Efficient  methods  for  the  repetitive  solution 
of  large  sets  of  ODEe  should  therefore  be  pursued . 

Seider  and  Hhite  III:  Yes ,  George  Byrne  answered  my  question 
( Seider )  by  stating  that  discontinuities  in  the  results  of  the 
numerical  integrator  cause  problems  for  nonlinear  programming 
algorithms  that  approximate  a  Beeeian  matrix ;  for  example ,  using 
Powell’s  method .  This  problem  needs  to  be  resolved.  However,  in 
addition,  methods  to  avoid  a  complete  integration  for  each  set  of 
parameters  should  be  examined . 

Shampine:  My  own  research  has  not  been  directed  at  such  issues 
although  I  think  about  them  from  time  to  time .  I  do  not  see  how 
one  can  avoid  considering  the  interactions . 

Wendt:  Yes  —  again  with  detailed  kinetics .  Sensitivity 
analysis  and  parameter  estimation  are  most  important . 

QUESTION  8:  What  will  be  the  Major  advancements  in  simulation  of 
stiff  systems  in  the  near  and  far  terms?  Are  these  of 
fundamental  primary  interest  or  are  they  secondary  improvements? 


Bickart:  In  the  analysis  of  very ,  very  large  sets  of  equations 

--  really,  the  systems  they  describe  —  mixed  mode  analysis  and 
the  eoneept  of  latency  have  come  to  the  fore  as  a  means  of 
reducing  the  problem  size  to  manageable  proportions . 

Byrne:  Automatic  stiffness/nonstiffness  detection  and  method 

switching  with  dynamic  memory  allocation  ~  prototypes  availabe 
now  will  become  standard • 

Cellier:  •••Certainly,  parallel  processing  may  bring  some  key 

impulses  into  the  game •  Some  problems  may  become  solvable  which 
are  currently  simply  too  expensive  to  solve •  Whether  the 
algorithms  themselves  may  still  improve  very ■  much,  I  do  not 
know, • .Certainly ,  the  software  will  --  and  has  to  —  improve •  In 
particular,  the  modularity  of  code  has  to  be  improved,  and  the 
interfaces  have  to  be  better  defined  (e.g.f  with  respect  to  the 
data  involved  ~  large  systems  mostly  require  a  large  amount  of 
data  to  be  entered;  for  this  purpose,  an  appropriate  interface  to 
a  data  management  system  should  be  defined. 

>:  c 

Churchill:  I  expect  new  special-purpose  algorithms  will  be 

developed •  They  may  in  some  cases  involve  general  principles • 

Bdaberg:  Easier-to-use  software  for  nonexperts  —  primary 
interest;  automatic  scaling  of  ODEs  —  secondary  interest; 
sensitivity  analysis • 

Bnright:  I  see  three  distinct  developments  which  are  of 

fundamental  importance: 

(1)  The  development  of  more  effective  techniques  vAiieh  can 
exploit  special  structure  euoh  as  only  a  few  transients 
or  weak  coupling  between  subsystems j 

(2)  The  acceptance  by  software  developers  of  a  uniform 
interpretation  of  accuracy •  This  will  enable  users  to 
view  packages  more  as  black  boxes } 

(2)  Jffte  acceptance  and  wide  distribution  and  publication  of 


new  improved  package e  as  they  become  available .  (This 
can  beet  be  accomplished  through  meetings  such  as  this 

°n*0 

Gear:  Better  techniques  for  handling  the  linear  algebra  in  very 

large  problems .  Techniques  for  decoupling  subsystems . 

Gellinas:  Those  associated  with  solving  extremely  stiff  PDEe 

with  newly  emerging  adaptive  mesh  techniques  —  both  near  and  far 
term .  Ve  are  now  seeing  fundamental  advances  in  this  area  which 
will  require  extremely  robust  ODE  (and  linear  system)  solvers . 

Hindaarsh: 

(1)  Better  automation. 

(2)  Larger  computer  capacity  and  higher  speeds  will  help  a 
lot  even  with  present  methods. 

(3)  Advances  in  sparse  nonlinear  algebraic  system  methods , 
with  and  without  consideration  of  special  machine 
architecture ,  will  contribute  greatly. 

(4)  Better  interfaces  with  users ,  via  discipline- dependent 
simulation  software ,  will  be  of  secondary  importance. 

Krogh:  Better  reliability  and  efficiency.  Primary  ve.  secondary 
is  hard  to  answer,  but  I'd  probably  choose  the  latter.  But  the 
improvements  to  be  had  are  well  worth  doing. 

Mattheij  and  Soderlind:  ...the  gap  between  theory  and  software 
will  decrease .  Such  advancements  are  important  although  they  may 
not  have  a  large  influence  on  the  software  design.  The 
importance  is  mainly  from  the  robustness  point  of  view  —  a  more 
rigorous  theorstical  framework  is  needed  to  sustain  black-box  use 
of  the  software,  especially  in  nonlinear  applications. 

Miranker:  ...ill-conditioned  problems  generally  (PDEe,  integral 

equations,  turning  points ,  highly  oscillatory) .. . 


O'Malley:  I  believe  extension  of  related  research  to  partial 

differential  equations  and  boundary- value  problems  will  require 
fundamental  new  concepts . 

Petzold:  Some  of  the  areas  ufc ere  we  can  expect  (or  hope)  to  see 

major  advancements  in  the  near  future  are: 

( 1 )  solution  of  differential/algebraic  systems ,  and  more 
generally ,  constrained  differential  systems ; 

(2)  solution  of  highly  oscillatory  ODEe ; 

(3)  global  error  estimation  for  stiff  ODEe ; 

(4)  inexpensive  solution  of  small  systems  which  must  be 
solved  repeatedly; 

(5)  better  diagnostic  messages  for  stiff  solvere • 

(Of  course,  not  all  of  these  proboems  are  stiff ,  depending  upon 
your  definition. )  These  problems  are  of  primary  interest .  It 
would  require  quite  a  few  pages  to  list  problems  of  secondary 
importance. 

V  : 

Pratt:  Special-purpose  or  hardwired  computers ,  and  rewriting  or 

reeeleeting  algorithms  to  take  advantage  of  computer 
architecture;  in  short ,  doing  for  stiff  systems  what  has  been 
done  for  Fourier  transforme  in  signal  processing  hardware! 

Schiesser:  ...the  development  of  integrators  which  can  handle  a 

changing  number  of  ODEe  during  the  solution  to  accommodate 
adaptive  regridding  in  the  solution  of  IDEs. 

Thompson:  The  incorporation  of  stiff  system  methodology  into 

widely  available  simulation  packages ,  adequate  implementation  of 
root-finding  techniques ,  valid  automatic  stiffness  detection  and 
method  switching ,  and  global  error  estimation ,  ys  of  fundamental 
and  primary  importance.  Potential  advanoes  in  partitioning  and 
subsystem  identification  are  at  least  of  secondary  importance. 
Alto  of  crucial  importance  are  the  needed  improvemente  in 
documentation  and  the  development  of  reliable,  user-friendly 
eo ft  ware. 
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Wendt:  I  think  that  current  technology  on  rapid  Poieeon  solvere 
and  techniques  for  handling  large  systems  involving  hugjt  matrices 
will  evolve  from  the  classified  literature  and  become  very  useful 
for  stiff  problems .  I  don't  know  much  about  them ,  but  I  hear  -- 
through  the  grapevine  —  that  very  powerful  computational 
techniques  have  been  developed  by  BOD  and  could  be  very  useful  in 
many  other  applications  --  such  as  stiff  boundary- value 
problems .  These  would  involve  radical  changes  in  how  stiff 
problems  are  attacked  and  solved . 


Comments  on  questionnaire  •» 

Table  8.1  contains  the  number  of  responses  to  each  question; 
/  ^ 

generally,  the  most^answered  questions  were  answered  in  greatest 
detail.  The  most  popular  —  and  most  emotional  —  questions  were 
Nos.  1  and  3.  Opinions  on  question  No.  1,  concerning  use  of  the 
word  'stiff'  fell  basically  into  two  categories:  practitioners 
who  want  a  free  hand  with  the  useage,  and  developers/theorists 
who  want  a  precise,  restricted  useage.  The  almost  universal 
answer  to  Question  No.  3  was  that  automatic  packages  should  be 
automatic  to  the  limit,  with  options  for  control;  significant 
advances  (in  addition  to  ultimate  robustness)  are  seen  for 
special  problem  types. 
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TABLE  8.1 


Number  of  responses  to  stiff  questions 


Question  No, 


No.  of  responses 


Questions  Nos.  2,4,5,  and  8  drew  about  the  same  number  of 
responses.  From  Question  No.  2,  we  would  conclude  that  there  has 
not  been  much  interaction  between  hardware  people  and  software 
people,  but  the  usefulness  of  such  interaction  is  definitely 
recognized.  It  is  clearly  realized  (Question  No.  4)  that  theory 
lags  well  behind  practice  in  stiff  computation  (unlike  in  many 
other  areas  of  science).  Question  No.  5  resulted  in  a  variety  of 
most  important  application  areas  being  mentioned,  but 
particularly  those  involving  partial  differential  equations  and 
large  numbers  of  equations;  this  was  echoed  in  answer  to  Question 
No.  8  on  what  the  major  advances  will  be. 

Questions  No.  €  and  7  were  not  answered  nearly  as  often  as 
the  others,  and  this  could  be  significant.  Generally,  few 
respondees  could  cite  cases  where  stiffness  was  necessary  to  the 


model  (Question  No.  6).  The  idea  of  'system  analysis'  for  stiff 
computation  (#2.1)  was  definitely  regarded  as  important,  as  was 
the  parameter  estimation  problem,  but  these  notions  were 
considered  new  (Question  No.  7). 

A  ninth  question  was  asked  concerning  the  usefulness  of  the 
Park  City  meeting.  The  consensus  was  that  it  was  a  very  good 
idea  to  bring  together  individuals  with  widely  differing 
backgrounds  that  share  a  common  problem  area.  This  would  support 
the  response  sparsity  to  Questions  Nos.  6  and  7. 


8.2.  Panel  discussion  at  International  Conference  on  Stiff 
Computation,  Park  City,  Dtaht 

SB AMPINS:  Ve've  heard  during  these  talks  so  far  quite  a  lot  of 
computation  described  as  et if f .. .anyone  have  opinions? 

GEAR:  Yes. . .the  purpose  of  having  a  classification  and  giving 
names  to  classes  is  to  group  them  into  moderate  size  groufi^i  if 
you  say  a  problem  belongs  to  class  x,  then  you  can  say  it  can  be 
solved  by  certain  methods*  ..it  is  madness  to  classify  BVPs  that 
require  totally  different  techniques  from  IVPs  as  being 
stiff... BVPs  are  unstable  as  well  as  stable... in  both  directions , 
while  stiff  problems  are  strongly  stable  in  one .direction. 

MIRANKER:  This  guy  was  walking  down  a  street  in  Hew  York  and 
passed  this  store  in  which  he  saw  a  sign  that  said  'Stiff 
Differential  Equation  Solver .'  Be  quickly  van  into  the  store  and 
said  ' can  you  solve  my  stiff  differential  equation ?'  The 
storekeeper  said ,  'I  don't  know  what  you're  talking  about ,  I  make 
eigne  l ' 


sss 

SHAMPINE:  Many  people  think  that  our  problems  will  be  mopped  up 
if  we  fust  build  a  bigger  computer ..  .or  many  more  little  tiny 
computers .. .what  implications  (from  next  generation  computers) 
does  this  have  on  software  and  algorithmic  developments? 

HIHDMARSH:  There  are  going  to  be  some  minor  changes  as  a  result 
of  new  architecture ,  but  I  don't  think  they  are  going  to  be 
profound  as  far  as  the  stiff  computation  problem  is  concerned. 
Be  are  going  to  tee  higher  speeds ,  certainly ,  and  we  are  going  to 
sss  far  greater  use  of  parallelism ,  and  we  will  have  to  try  to 
make  use  of  that  new  architectural  environment ,  but  the  obstacle 
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we  refer  to  ae  etiffneee  will  etill  be  around.  •  .the  most  that 
will  happen ,  I  think ,  ie  that  the  boundary  between  mildly  etiff 
probleme  and  the  etiff  problem  will  move  a  bit.  But  the  really 
etiff  probleme  will  be  around .  * 

Et RIGHT:  What  about  the  emphaeie  of  different  codee?  For 
example ,  extrapolation  codes  become  more  competitive  ae  we  get 
into  parallel  architecture ... 

HINDMARSH:  They  may  very  well... What  I'm  saying  will  not  happen 
ie  we  will  fall  back  on  nonetiff  methode  and  do  everything 
explicitly . 

PRATT:  ...I've  been  trying  for  some  yeare  to  solve  large-scale 
eyeteme. .  .what  I  see  happening  ie  ae  we  get  bigger  and  bigger 
computers  we  can  do  things  faster  and  faster,  but  we  will  always 
want  to  solve  bigger  probleme  and  we  need  eophietication  at  the 
low  end  of  the  scale... 

BTRNB:  ...there  are  two  obvioue  directions  that  computing  is 
moving... the  day  is  not  far  off  when... every  engineering 
professional  will  have  on  hie  desk  a  mini  which  ie  linked  to  a 
supercomputer  mainframe. . .this  ie  mind-boggling .. .the  mainframe 
ie  probably  going  to  be  a  big  parallel  processor .. .we  see  in  the 
literature  snake  algorithms. . .you  put  something  on  your  mini  and 
it  snakes  out  for  unused  mini- computers  in  the  network. . .you  have 
all  this  computing  power.  What  is  the  impact  on  stiff 
computation?  There  will  be  a  change  obviously  in  the 
algorithms .  The  linear  algebra  will  be  changed  dramatically .. .we 
will  see  much  more  detailed  modelling ... 

sss 

8BAMPINE:  Many  people  feel  (the  etiff  problem)  ie  rather  mopped 
up.  ..I  think  we  need  to  have  a  period  of  true  confession. .  .what 
areas  do  we  not  know  what  we're  doing  or  don't  know  how  to  do 


anything  at  all...thie  is  an  opportunity  for  you  to  say  where  you 
think  things  are  going,,. (for  example)  Runge-Kutta  methods  for 
stiff  problems ,  we're  just  beginning  to  explore  them,.. doing  an 
integration  and  locating  where  some  function  had  a  zero,  our 
theoretical  and  practical  understanding  of  that  problem  is  almost 
zero.  There  are  terrible  difficulties  in  stating  theoretically 
what  it  means  to  locate  a  root  of  a  function  when  that  function 
is  being  defined  by  the  noisy  process  of  solving  a  differential 
equation. . .it ' e  easy  to  write  down  something  that  sort  of 
works .. .there' e  one  example  of  a  true  confession. . . 

PETZOLD:  ...I  don't  think  anyone  really  has  a  good  understanding 

of  nonlinear  differential  algebraic  equations ,  in  general,  and 
there's  this  whole  question  of  turning  points ... 

CASH:  Some  problems  we  can  get  nowhere  with... a  boat  connected 

to  the  shore  and  the  tension  in  the  chain  is  some  random 
variable,  stochastic  differential  equations ... 

SSS 

*.  SHAMPINE:  Stability  analyses  have  been  tilled  since  the  earlier 
days... Some  of  us  think  this  has  very  little  to  do  with  practice, 
but  I  have  a  feeling  at  the  current  time  stability  analysis  is  in 
a  real  state  of  ferment  and  that  the  theory  is  moving  closer  to 
the  practice ... 

DAHLQUIST:  I'm  glad  to  hear  you  say  that.  Veil,  of  course  we 

try.  All  theory  must  be  based  on  simplifications .. .see  how  much 
one  can  do  with  simple  model  problems .. .1  think  all  progress  must 
be  based  on  this  --  that  one  makes  a  theory  or  makes  software  for 
some  standard  situations. . .Henrici  hoped  when  he  wrote  his  book 
that  the  theory  or  .  practice  of  differential  equations  could 
be  handled  fust  by  the  assumption  that  the  step(eXse  times  the 
Lipeohitz  constant  should  be  chosen  sufficiently  small.  Then  it 
became  more  and  more  obvious  that  there  were  practical  problems 


for  which  this  was  not  the  ease .  My  own  experience  at  the  time 
was ,  at  the  beginning  of  the  fifties,  I  encountered  one  problem 
where  this  difficulty  existed .  I  tried  to  ask  a  lot  of  people 
from  different  application  disciplines  if  they  recognised  this 
kind  of  situation  and  everybody  said,  ' No '.  Around  1960,  things 
became  completely  different  and  everyone  became  aware  that  the 
world  was  full  of  stiff  problems .  Even  if  a  theoretician  tries 
to  get  a  good  formulation  of  the  real  problems ,  it  is  sometimes 
really  difficult  to  get  them  so  well  formulated  that  it  can  be  a 
good  starting  point  for  a  theoretical  analysis .. .to  return  to 
differential  algebraic  equation  analysis .. .it  is  still  a  little 
uncertain  how  many  real  nasty  situations  are  left  that  require  a 
general  theory... a  lot  of  practical  situations  particularly  in 
classical  mechanics  are  differential  equations  with  inequality 
constraints .. .think  of  all  the  problems  with  Couloub'e  Law  of 
friction. . .or  two-body  collisions,  it  is  an  inequality  constraint 
that  they  are  not  allowed  to  penetrate .. .perhaps  you  should  widen 
the  discussion  of  differential  algebraic  systems  also  to  cover 
the  case  of  inequalities ...I  would  really  like  to  hear  about 
other  applications  (of  differential  equations  with  inequality 
constraints ) . . . 
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SHAMPINE:  My  impression  is  we  have  no  satisfactory  way  of 

solving  delay  or  difference  differential  equations. . . 


BICKART:  Some  of  the  codes  work  well... as  soon  as  you  run  into 

nonconstant  delays  you  run  into  problems . 


SSS 


KROGBt  I  don't  know  what  the  theoretical  problems  are  with 
handling  discontinuities,  but  I  haven't  seen  any  practical 
difficulties.  I  have  had  features  for  handling  discontinuities 
in  my  codes  since  1969 ... 


mC  'll) 


SHAMPINE:  That's  because  you  have  infrequent  discontinuities .. . 
KROGH:  The  difficulty  is  in  the  restarting? 

SHAMPINE:  The  order  plummets .  It  has  a  disastrous  effect  if  it 

happens  often  enough. 
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SHAMPINE:  The  inverse  problem  of  parameter  estimation  is 

certainly  a  very  difficult  problem. . . 

BYRNE:  The  difficulties  are. . .the  kinetics  themselves  are 
wicked... you  start  off  with  so-called  literature  rate 
coefficients  which  for  the  particular  system  at  hand  aren't 
really  right  so  you're  really  off  the  mark  for  a  starting 
point .. .generally  you  have  interval  constraints .. .we  need  a  cheap 
nonlinear  constrained  least- square  package .. .the  problem  is  quite 
typically  badly  scaled... 

CHURCHILL:  It's  an  impossible  problem.  There  is  a  non¬ 

uniqueness  that  will  never  be  solved  by  any  package. .  .you  never 
will  have  good  enough  information  so  that  you  can  trust  what  you 

get  •  •  • 

DOVE:  ...virtually  no  kinetic  experiment  gives  you  information 

on  one  rate  constant  only... there  is  information  on  several 
constants  and  that  information  has  to  be  unscrambled. . . 

PRATT:  ...we  mustn't  forget  the  third  leg  of  this  thing  and  that 
is  sensitivity  analysis. . .without  it  you're  groping... 

SBIDBR:  We've  had  a  great  deal  of  success  in  tuning  the 

parameters  in  (models  of)  non^iieal  solutions  with  Powell's 
nonlinear  programming  algorithm  written  in  1977 ;  it's  very  good 


for  highly  nonlinear  functions  ae  well  ae  highly  nonlinear 
constraint e • . * 
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BYRNE:  It  doesn't  work  out  for  us  •••the  line  search  is  too 

expensive • 
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SH AMPINS:  When  we  actually  get  down  to  solving  a  problem  we  have 
to  choose  a  solver  to  do  it •••we  have  actually  to  pick  one, ..how 
do  we  decide? 

ENRIGHT:  •••we  can  certainly  identify  some  codes  that  are  not 
competitive •• .testing  will  allow  us  to  choose  between  two 
algorithms  that  have  a  very  similar  design  structure,  but  to 
compare  two  codes  with  very  different  structure  I  think  is  almost 
impossible  unlese  we  restrict  the  class  of  problems  to  a  very 
email  close  that  exhibits  a  special  structure. •• 

PRATT:  •••How  do  we  chose  between  a  BMW  and  a  Vespa? 

BYRNE:  I  think  we  all  have  built-in  prejudices, . .if  you  use  a 
code  and  you're  not  comfortable  with  it,  you're  not  going  to  use 
it  again • 

ENRIGHT:  ... the  problem  here  is  that  codes  aren't  trying  to ^ 
the  same  things.  Twenty  years  ago  they  were.  Fixed  stepwise  we 
could  compare •• .now  codes  determine  accuracy  requirements  in  a 
completely  method- dependent  way... 
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